首先身為面試官的立場自然是站在公司這一邊的，必須要了解公司為什麼會開出這個職缺？是因為公司體制的擴編？還是因為人力的流動？希望應徵進來的成員的程度如何？主管也提醒我們要思考該應徵者或許之後會成員我們團隊中的一員，是否能與其合作相處、互相砥礪，如此一來在面試的時候才能有效的篩選適合的成員。

由於我即將轉調到下一個專案，所以原專案需要一名成員來接替，那原專案的成員組成只有我一名 Back-End，所以我會希望來接替的成員能擁有獨立開發，就算能力不到也要能快速的在一個月內上手，所以我也會注重溝通能力及技術提升潛力。

所以在這次的面試預計要應徵的程度為 Junior - Middle 之間，我準備了一個題目由此來觀察應徵者的程度及溝通能力，由於此職缺的 JD (Job Description) 上有註明希望應徵者有使用 Laravel 的經驗，所以會優先請應徵者使用 Laravel 的通用方式來完成。題目如下：

1. 五大 Entity ，使用者(User) 需有「名稱/手機號碼」，商品種類(Product)需有「商品名稱/定價」，商品細節(ProductDetail)需有「大小/顏色/數量庫存」，購買訂單(Payment)需有「總價/訂單狀態」，訂單細節(PaymentDetail)需有「商品資訊」
2. 題目隱藏了些許關聯細節，需自行設計發揮
3. API - 商品Index (列出所有商品)
4. API - 訂單 Index (列出所有訂單)
5. API - 訂單 create (建立訂單)
6. API - 訂單細節 Detail (列出指定訂單的訂單、訂單細節、商品、購買者資訊)

如果應徵者能順利地回答出這些題目，代表對於框架有基本的了解、資料庫的設計也沒問題、也可以在過程中了解其表達能力，約十位的應徵者年資大約落在一至三年，據我自己的經驗此時要應付這個題目應該是游刃有餘的，但人生中就是有這個 BUT。有些應徵者雖然有 Coding 的能力但是沒有資料庫設計的概念，原因為之前的工作只被分配到使用原本就設計好的資料庫來做 CRUD 而已，也有些應徵者雖然有辦法設計出正規化的資料庫，但關聯資料的方式卻不是很好，可能是使用了錯誤的關聯方式、或是用法會造成效能上大量的損耗。更有些應徵者連題目都沒有看清楚便開始作答，讓我十分懷疑人生究竟是我的表達能力不好還是過程中出了什麼問題，後來與會的主管也有教我一些引導的技巧，讓我在後面的面試中能更好的與應徵者溝通，最終也順利的找到了適合的工作夥伴，明天就來談談過程中遇到的神奇設計吧。